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Description 

PRESENCE REGISTRATION AND ROUTING NODE 



Related Application Information 
This application claims the benefit of United States Provisional Patent 
Application Number 60/191,278, filed March 22, 2000, the disclosure of which 
is incorporated herein by reference in its entirety. 

Technical Field 

The present invention relates to presence database services, and more 
particularly to the routing and processing of presence service related signaling 
messages in a communications network. 

Background Art 

Instant messaging (IM), as it is currently known within the 
communications industry, is an Internet technology that allows subscribers to 
send and receive text messages, voice messages and other data in near real- 
time. While IM started as a way to chat with friends, the technology has 
become an essential tool for many businesses, as it offers the convenience of 
e-mail and the immediacy of a phone call, as well as file transfers and voice 
messaging. 

Instant messaging is possible because the people sending and 
receiving messages remain constantly connected to their IM service. 
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Recipients get messages as fast as the data can travel across the Internet. 
Conventional e-mail, on the other hand, is less immediate. E-mail technology 
sends messages to a server that stores the items until they are downloaded 
by the recipient's e-mail software. Many industry experts argue that it is the 
5 "instant" or near real-time communication characteristic that has made and 
will continue to make IM a mode of communication in the future. 

At present, when a subscriber logs in to an IM service, the subscriber's 
software notifies a presence server or similar client based presence system 
that the subscriber is available to receive messages. Such a scenario is 
O 10 generally illustrated in Figure 1. Once the subscriber is logged in or 
Jjj "registered," the subscriber can choose to send a message to another online 

f J1 user. From a network communication perspective, such a communication is 

accomplished via the sending of data packets containing address and user- 
type information to the intended recipient. Depending on which service is 
15 used, a server either directly relays the message to the recipient or facilitates 
a direct connection between the sender of a message and the recipient. In 
Figure 1, communication between IM clients 100 is facilitated by presence 
server 102. In order to communicate with other instant message clients, 
subscribers send registration messages to presence server 102. The 
20 registration messages may contain contact information for IM clients 102. A 
proposed presence protocol for performing registration and subscription 
services will be discussed in more detail below. 

IM services typically employ one of three means to move messages 
around: a centralized network, a peer-to-peer connection, or a combination of 
25 both. In a centralized setup, users are connected to each other through a 
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series of data servers. Such servers effectively form a wide area network 
(WAN). Consequently, when an instant message is sent by a subscriber, at 
least one of the data servers finds the intended recipient's PC address and 
routes the message through the network until it reaches its destination. 

InYfre-p^er-to-peer approach, a central server maintains a database of 
online subscribers ancKtieir associated Internet Protocol addresses. After a 
subscriber logs in, such a servfef^ends the subscriber the IP addresses of 
everyone on their contact list who is also&urrently logged on. 

When a subscriber wishes to send an instant message to another user, 
10 the subscriber's client sends the IM directly to the user's client, without 
involving the server. As such, all IM message traffic does not necessarily go 
-y through the entire network. Such an architecture tends to result in improved 

a y network performance, as compared to other IM schemes. 

□ An excellent discussion of a proposed presence protocol can be found 

~U 15 in "The Presence Protocol," internet-draft-saraswat-presenceprotocol-OO.txt, 
^ February 26, 1999, the disclosure of which is incorporated herein by reference 

in its entirety. In the proposed presence protocol specification, a presence 
server is defined as a server that manages presence information for a 
collection of entities, subscriptions to those entities, and their privacy 
20 restrictions. 

Each server has an address at which presence messages may be 
delivered. Presence information is defined in the proposed presence server 
protocol specification as information such as presence status, current point-of 
presence (if any), idle time, etc., for an entity. As used herein, the term 
25 presence information refers to any information regarding an end user or entity, 
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including, but not limited to: end user location, end user status, media 
capabilities of a telephony gateway associated with the end user, end user 
directory number, end user IP address, etc. 

entity has control over publication of its presence information. An 
entity is defined as the unit, e.g. a person, on whose behalf presence 
information is beihg maintained. Each entity has a unique handle. The 
identity of the presence^erver maintaining presence information for the entity 
can be determined from tnk handle. A handle is well known name for an 
( entity. An example of a hancfte is pp://www.intercom. att.com/TyrantRana. 



10 Finally, a point of presence (PoP) i& defined as a point of presence for an 
entity. If an entity is present, it is connected to one PoP. Each PoP has an 
address, e.g., an IP address and a port number, at which presence messages 
may be delivered. 

A typical example of how the presence protocol may be used is as 
15 follows. An entity A connected to an endpoint E may subscribed through a 
presence server P to another entity B. When the status of B changes, P will 
notify E of the change in status of B, if B's privacy specifications allow. If P is 
unable to notify E, for instance, because E is unreachable, P marks E as 
absent and will subsequently not attempt to deliver to E until E reestablishes 
20 its presence. In addition, P may periodically ping an endpoint for current 
status information on the entities connected through that endpoint. Such a 
heartbeat from the presence server ensures that presence information stored 
at the server is current. 

Once presence information about an entity is delivered to an endpoint, 
25 the endpoint may directly contact the entity. Protocols for exchanging instant 
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messages, file transfer, etc. between two such end points are not defined in 
the above-referenced presence protocol specification. Similarly, the protocol 
used for communication between clients and PoPs is outside the scope of the 
presence protocol specification. In addition, the transport protocol used to 
5 deliver presence messages including presence registration and update 
messages is not defined in the presence protocol specification. 

One thing that the presence protocol specification does specify is 
message types used to perform presence-related actions. It is these 
message types that may be sent by a presence server to update and obtain 
C3 10 presence information from a presence database. The message types include 
Cn an assert message, which is sent by a PoP whenever the presence 

If information associated with an entity changes. A fetch message is a request 

i]\ sent to the presence server to obtain presence information regarding a target 

h specified in the fetch message. A subscribe message is a message sent to 

ry 15 the presence server to allow the subscriber to receive presence information 
£3 updates regarding a target specified in the subscribe message. A notify 

message is a message sent by the presence server to a requestor or a 
subscriber to convey presence information about a named entity. 

TFfer^are currently models, including the models described above, that 
20 provide for instarTSqriessaging (IM) and presence services within the scope of 
an Internet Protocol / cUita network environment. It will be appreciated from 
the discussion above that one^of the key elements of IM operation involves 
the ability for one subscriber to "know!!, when another subscriber is logged in 

X 

or is "available." From the discussion abovq, it will also be appreciated that 
the ability to track the login status, otherwise knoWn as "presence," of Internet 
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ussrs is fairly well developed and widely practiced. However, as 
comirumication networking technology has continued to evolve at a rapid 
pace, so\iave the means by which end users or subscribers can 
communicate. NVIore particularly, the explosive growth of hand-held, wireless 
5 communication terminals, such as cell phones, wireless WEB phones, and 
personal digital assistants has led to a demand for inter-networking or inter- 
medium communication solutions. In other words, it is rapidly becoming 
useful for a subscriber to have their wireless phone status or "presence" 
known to other subscribers, whete these other subscribers may be using a 

10 variety of communication mediums, such as wireless phone service, wired 
phone service, short message service (SMS), or Internet service. 

At present, such data network-based presence models do not address 
the implementation of these services within a traditional Public Switched 
Telephone Network (PSTN) environment. Again, with the continuing 

15 movement towards the convergence of data and telephony networks, there 
exists the need to provide a system and method of enabling instant 
messaging and presence services in a communications environment that 
includes components of both traditional data and traditional telephony 
networks. Therefore, what is needed is an instant messaging / presence 

20 model for use in a converged data and telephony network. 



Disclosure of the Invention 
According to one aspect, the present invention includes a presence 
registration and routing node. The presence registration and routing node 
25 receives a signaling system 7 (SS7) message in response to a telephony- 




related action, such as the activation of a mobile handset, the dialing of a 
directory number to establish a call, or the entry of predetermined DTMF 
digits. In response to the SS7 message, the presence registration and routing 
node formulates a presence-server-compatible message for updating 
presence information regarding an end user in a presence server database. 
The presence-server-compatible message may be in any presence-server- 
compatible format, including session initiation protocol (SIP), presence, and 
Instant messaging and presence protocol (IMPP). SIP is defined in RFC 
2543, SIP: Session Initiation Protocol (March 1999), the disclosure of which 
is incorporated herein by reference in its entirety. IMPP is defined in RFC 
2778, A Model for Instant Messaging, (February 2000) and in RFC 2779: 
Instant Messaging / Presence Protocol Requirements (February 2000), the 
disclosures of each of which are incorporated herein by reference in their 
entirety. Presence is defined in a variety of documents, including the IETF 
Internet draft mentioned above and other IETF documents that will be 
discussed below. The present invention is not intended to be limited to any 
specific presence protocol format. The formats discussed herein are 
examples of presence protocol formats suitable for use with the present 
invention. 

According to another aspect, a presence registration and routing node 
includes an advanced database communications module (ADCM) for 
receiving queries for presence\information. The ADCM module forwards the 
queries to a presence application, such as a SIP, IMPP, or presence 
application. The presence application formulates a presence-server- 
compatible message, forwards the presehce-server-compatible message to a 



presence^atabase, receives a response from the database, an forwards the 
response to thesADCM module to be sent to the requestor over an IP network. 
The presence database may be internal or external to the presence 
registration and routing |Hode. 

Some aspects of the invention will be explained in terms of modules 
and processes. It is understood that these modules or processes may be 
implemented in hardware, software, or a combination of hardware and 
software. Exemplary hardware upon which the processes and modules 
described below may execute includes a microprocessor, such as an Intel 
Pentium® processor and associated memory. Each of the modules in a 
presence registration and routing node according to the present invention may 
be a printed circuit board with a microprocessor and memory located thereon. 
The microprocessor may execute one or more computer programs for 
performing the presence registration and routing functions discussed below. 

Accordingly, it is an object of the present invention to provide a 
presence registration and routing node for receiving SS7 messages in 
response to telephony-related actions and formulating presence-server- 
compatible messages in response to the SS7 messages. 

It is another object of the present invention to provide a presence 
registration and routing node for receiving Internet Protocol (IP) encapsulated 
SS7 messages in response to telephony-related actions and formulating 
presence-server-compatible messages in response to the SS7 messages. 

It is another object of the present invention to provide a presence 
registration and routing node capable of routing presence-server-compatible 




messages to a presence database and forwarding responses from the 
database over an IP network. 

It is another object of the present invention to provide a presence 
registration and routing node that includes an internal or integrated presence 
5 database. 

It is another object of the present invention to provide a presence 
registration and routing node that is adapted to maintain accounting or billing 
information related to presence database access. 
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Cn Brief Description of the Drawings 

Preferred embodiments of the invention will now be explained with 
r\ reference to the accompanying drawings of which: 

r% Figure 1 is a block diagram illustrating conventional presence and 

py 15 instant messaging message flow; 

□ Figure 2 is a block diagram of an SS7/IP gateway that may be modified 

to perform presence message processing according to embodiments of the 
present invention; 

Figure 3 is a block diagram of a presence registration and routing node 
20 according to an embodiment of the present invention; 

Figure 4 is a block diagram of a presence registration and routing node 
according to an embodiment of the present invention; 

Figures 5a^n€L5b are a flow chart illustrating exemplary steps that 
may be performed by a presence^egjstration and routing node in processing 
an IAM message according to an embodiment^nhe present invention; 





Figure 6 is a block diagram illustrating SCCP encapsulation of an ISUP 
1AM message; 

Figure 7 is a flow chart illustrating exemplary steps that may be 
performed by a presence registration and routing node in processing a TCAP 
message according to an embodiment of the present invention; 

Figure 8 is a block diagram illustrating the operation of a presence 
registration and routing node in a mobile telecommunications network 
according to an embodiment of the present invention; 

Figure 9 is a block diagram illustrating the operation of a presence 
registration and routing node in processing an 1AM message according to an 
embodiment of the present invention; 

Figure 10 is a block diagram illustrating the operation of a presence 
registration and routing node for in processing a TCAP message according to 
an embodiment of the present invention; 

Figure 11 is a block diagram of a presence registration and routing 
node including an internal presence database according to an embodiment of 
the present invention; 

Figure 12 is a flow chart illustrating exemplary steps that may be 
performed by the presence registration and routing node illustrated in Figure 
1 1 in responding to a presence query for updating presence information 
according to an embodiment of the present invention; 

Figure 13 is a bio&Kdiagram of a presence registration and routing 
node including an external presenfce^latabase according to an embodiment of 
the present invention. 




Figure 14 is a block diagram of a presence registration and routing 
according to an embodiment of the present invention that includes a message 
accounting and billing subsystem; 

Figure 15 is a table that illustrates a sample usage and measurements 
5 database associated with a message accounting and billing subsystem of the 
present invention; and 

Figure 16 is a block diagram of a presence registration and routing 
according to an embodiment of the present invention that includes a presence 
database and message accounting and billing subsystem. 

10 

Detailed Description of the Invention 
The present invention includes a presence registration and routing 
(PRR) node for communicating with and routing messages between both 
Internet Protocol (IP) and Signaling System 7 (SS7) network nodes. In one 

15 embodiment, a PRR node employs an internal architecture similar to that of 
high performance STP and signaling gateway (SG) products which are 
marketed by Tekelec, Inc., of Calabasas, California as the Eagle® STP and 
IP 7 Secure Gateway*" 1 , respectively. A block diagram that generally illustrates 
the base internal architecture of the Eagle® STP product is shown in Figure 2. 

20 A detailed description of the Eagle® STP may be found in the Eagle® Feature 
Guide PN/91 0-1 225-01, Rev. B, January 1998, published by Tekelec, the 
disclosure of which is incorporated herein by reference in its entirety. 
Similarly, a detailed description of the IP 7 Secure Gateway 1 " 1 may be found in 
Tekelec publication PN/909-0767-01, Rev B, August 1999, entitled Feature 

25 Notice IP 7 Secure Gateway*™ Release 1.0, the disclosure of which is 



incorporated herein by reference in its entirety. The specific functional 
components of an IP 7 Secure Gateway tm for transmitting and receiving TCAP 
messages over an Internet Protocol (IP) network are described in commonly- 
assigned, co-pending International Patent Publication No. WO 00/35155, 
5 Published June 15, 2000, the disclosure of which is incorporated herein by 
reference in its entirety. As described in the above referenced Eagle® Feature 
Guide, an Eagle® STP 250 includes the following subsystems: a Maintenance 
and Administration Subsystem (MAS) 252, a communication subsystem 254 
and an application subsystem 256. The MAS 252 provides maintenance 

10 communications, initial program load, peripheral services, alarm processing 
and system disks. The communication subsystem 254 includes an 
Interprocessor Message Transport (IMT) bus that is the main communication 
bus among all subsystems in the Eagle® STP 250. This high-speed 
communications system functions as two 125 Mbps counter-rotating serial 

15 buses. 

The application subsystem 256 includes application cards that are 
capable of communicating with the other cards through the IMT buses. 
Numerous types of application cards can be incorporated into STP 250, 
including: a Link Interface Module (LIM) 258 that provides SS7 links and X.25 

20 links and an Application Service Module (ASM) 262 that provides global title 
translation, gateway screening and other services. A Translation Service 
Module (TSM) 264 may also be provided to support triggered local number 
portability service. Once again, a detailed description of the Eagle® STP is 
provided in the above cited Eagle® Feature Guide and need not be described 

25 in detail herein. With particular regard to the signaling gateway (SG) product 
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line produced by Tekelec, it should also be appreciated that a Database 
Communication Module (DCM) 260 can be employed to provide for the 
transport of Internet Protocol (IP) encapsulated SS7 messages over an IP 
network, as described in the above referenced Feature Notice IP 7 Secure 
Gateway*™ Release 1.0 publication. With further regard to the TSM triggered 
LNP services module mentioned above, a detailed description of the Tekelec 
triggered LNP solution may be found in the Feature Guide LNP LSMS 
PN/91 0-1 598-01, Rev. A, January 1998, published by Tekelec, the disclosure 
of which is hereby incorporated herein by reference. Furthermore, systems 
and methods for providing triggerless LNP functionality within a network 
routing node are described in commonly-assigned, co-pending U.S. Patent 
Application No. 09/503,541, filed February 14, 2000, the disclosure of which is 
incorporated herein by reference in its entirety. 

SS7 MSU Triggered Presence Registration Message Generation 
v Shown in Figure 3 is a schematic diagram of a presence registration 



and routincJ^piQde 300 of the present invention. It will be appreciated that 
presence registratiorl\and routing node 300 includes a high speed 



Communicatively coupled to IMT oqs 310 are a number of distributed 
processing modules or cards includin^k a pair of Maintenance and 
Administration Subsystem Processors (MASPs)^12, an SS7 capable Link 
Interface Module (LIM) 320, an IP capable Advanced Database 
Communication Module (ADCM) 360, and a Presence Registration Module 
(PRM) 340. These modules are physically connected to the IM riaus 310 




Interprocessor Message 



sport (IMT) communications bus 310. 
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X$uch that signaling and other type messages may be routed internally 
betweer^all active cards or modules. For simplicity of illustration, only a single 
LIM 320, ADQM 360, and PRM 340 are included in Figure 3. However, it 
should be appreciafedthat the distributed, multi-processor architecture of the 
5 presence registration and routing node 300 facilitates the deployment of 
multiple LIM, ADCM, PRM, anb^ other cards, all of which could be 
simultaneously connected to the IMT buV310. 

MASP pair 312 implements the maintenance and administration 
subsystem functions described above. As the MASP pair 312 are not 
10 particularly relevant to a discussion of the flexible routing attributes of the 
present invention, a detailed discussion of their function is not provided 
herein. For a comprehensive discussion of additional MASP operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

Focusing now on LIM card functionality, it will be appreciated that LIM 
15 320 is comprfeedof a number of sub-component processes including, but not 
limited to; an SS7 MTP^exel 1 process 322, an SS7 MTP level 2 process 324, 
\ an I/O buffer or queue 325, SKgateway screening (GWS) process 326, a 
/Presence Registration Request (PRR^stop action process 328, an SS7 MTP 
/ level 3 layer HMDC process 330, and an HMQT process 332. MTP level 1 
20 and 2 processes 322 and 324, respectively, providettje facilities necessary to 
send and receive digital data over a particular physicaKmedia / physical 
interface, as well as to provide error detection / correction ancKsequenced 
delivery of all SS7 message packets. I/O queue 325 provides for temporary 
buffering of incoming and outgoing signaling message packets. G\ 
25 process 326 is responsible for examining the incoming signaling message and 



determining which, if any, of the provisioned stop actions are applicable. PRR 



\ stop action process 328 is responsible for making a copy of, and 
Subsequently encapsulating, an incoming SS7 ISDN User Part (ISUP) 1AM 
signing message packet within an SS7 Signaling Connection Control Part 
5 (SCCP)\formatted packet. It should be appreciated that PRR stop action 
process 328 could also be configured to simply encapsulate the original 
incoming SS7\SUP 1AM signaling message, without making a copy. MTP 
level 3 HMDC process 330 receives signaling messages from the lower 
processing layers &nd performs a discrimination function, effectively 
10 determining whether an\ incoming SS7 message packet requires internal 
processing or is simply to be through switched. For instance, in the case of 
an SS7 TCAP message associated with presence registration or an SCCP 
encapsulated ISUP IAM message^ HMDC process 330 would determine that 
the message should be internally routed for further processing. The HMDT 
15 process 332 manages or directs the internal routing of SS7 message packets 
that require additional processing prior to final routing. Once again, it should 
be appreciated that a LIM card may contain rnore functional processes than 
those described above. The above discussion\s limited to LIM functionality 
associated with the basic processing of in-bound signaling messages. 
20 As such, it will be appreciated that the three functional processes 

associated with an Advanced Database Communication Module (ADCM) 360 
shown in Figure 3 are simply those processes that are relevant to a 
discussion of out-bound ADCM operation in the examples of PS routing node 
operation disclosed herein. Furthermore, it will be appreciated that ADCM 
25 360 is similar in function to the DCM application module described above. In 
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the case of ADCM 360, the message packets processed by the card need not 
be native SS7 type messages that have been encapsulated in an IP packet. 
Instead, the ADCM 360 is capable of processing, transmitting, and receiving 
both native SS7 and native IP protocol messages. 
5 The processes explicitly shown on the out-bound ADCM 360 include 

an I/O queue 362 and IP level 1 and 2 processes 366 and 364, respectively. 
I/O queue 362 facilitates temporary buffering of incoming and outgoing 
signaling message packets, while IP addressing operations are performed by 
the IP level 1 and 2 processes 366 and 364, respectively. 
10 Once again, the description of LIM and ADCM sub-components 

provided in the above description is limited to those sub-components that are 
relevant to the sample implementation scenarios discussed herein. For a 
comprehensive discussion of additional LIM and ADCM-type operations and 
functionality, the above-referenced Tekelec publications can be consulted. 
15 In general, a PRM card includes the database and database control 

processes nebessary to achieve the presence registration message 
generation and rouuqg functionality of the present invention. The PRM 340 
shown in Figure 3 is colrjprised, in part, of an SCCP subsystem controller 
known as a Signaling Connection Routing Controller (SCRC) process 342, a 
Presence Registration Manager^J^RMG) process 344, and a number of 
Presence Registration Applications geherally indicated by the numeral 346. 
Included among the Presence Registration ^Applications is a session initiation 
protocol (SIP) registration application process 348 for generating SIP 
messages, forwarding the SIP messages to \ presence server, and 
25 processing SIP messages received from the presence^server. The format for 



SIP messages is described in detail in the above-referenced RFC 2543, which 
defines^ the SIP protocol. In addition, the portion of a SIP message that 
carries the>qedia capabilities information for an end user device is referred to 
as the session description protocol portion. The session description protocol 
5 is described in detaiNjn RFC 2327, "SDP: Session Description Protocol," 
(April 1998), the disclosure^ which is incorporated herein by reference in its 
entirety. 

Presence protocol process 349 may also be included for 
communicating with a presence server using the messages described in the 
10 above-referenced presence protocol specification. 

Instant messaging and presence protocol (IMPP) process 351 may 
also be included for communicating with a presence server according to the 
IMPP protocol. The IMPP protocol is described in detail above and in one or 
more of the following IETF Internet draft documents: 
15 "Message Information Data Format," <draft-ietf-impp-midf- 

01.txt>, January 19, 2000; 

"Presence Information Data Format for IMPP," 
<draft-ietf-impp-pidf-01.b<t>, March 10, 2000; and 
"Transport Protocol for Presence Information/ Instant 
20 Messaging," <draft-ietf-impp-pitp-mitp-01>, March 9, 2000, 

the disclosures of each of which are incorporated herein by reference in their 

entirety. 

The present invention is not limited to communicating with a presence 
server using SIP, IMPP, or presence protocols. Any protocol for 
25 communicating with a presence server is within the scope of the invention. 




\The SCRC process 342 is responsible for discrimination of signaling 
messages at the SCCP level, and for distributing the signaling messages to 
an appropriate higher processing level application or function. In the 
configuration \hown in Figure 3, the next highest processing level is 
5 represented by t^e PRMG process 344. PRMG process 344 is responsible 
for determining how\to process the incoming message packet. For instance, if 
the message packet (contains an SCCP encapsulated ISUP 1AM message, 
PRMG process 344 is\configured to de-capsulate the original ISUP 1AM 
message, and subsequently extract the appropriate information necessary for 
further processing from tKe de-capsulated message. However, if the 
incoming message were a TQAP formatted packet, no de-capsulation action 
would be required. In either case, PRMG process 344 is also charged with 
determining which of the provisioned presence registration applications is 
required for successful processing of a particular incoming signaling message 
15 packet. As will be appreciated from Figure 3, a number of presence 
registration applications may be simultaneously provisioned on a single 
PRMG card. These presence registration applications may be configured 
such that each application is capable oK generating presence registration 
messages that are formatted in different protocols including, but not limited to, 
20 SIP, IMPP, and presence protocol. 

While any of the above-described presence registration applications 
may be provisioned on a single PRM card, SIP registration application 348 is 
used in the examples described herein to illustrate the functionality of the 
presence registration and routing node in updating presence information in a 
25 presence server database and obtaining presence information. SIP 
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registration application 348 essentially contains the logic necessary to 
process the incoming SS7 message and construct the appropriate SIP- 
formatted presence registration message. 

Shown in Figures 3 and 4 are system level diagrams of one 
5 embodiment of presence registration and routing node 300 of the present 
invention. Also indicated in both figures are general message flows 
associated with the processing of incoming SS7 signaling packets and the 
generation of outbound presence registration messages. More particularly, 
Figure 3 illustrates the message flow associated with an incoming SS7 ISUP 
10 I AM message, while Figure 4 indicates the message flow associated with an 
incoming SS7 TCAP message. A detailed flow chart of the major steps 
associated with one particular implementation of the SS7 triggered presence 
registration message generation process is presented in Figures 5a and 5b, 
and may be used in conjunction with the schematic diagram shown in Figure 
15 3 to better understand the ISUP IAM based presence registration message 
generation methodology. 

Referring to Figure 5a, in step ST1, an incoming ISUP IAM message is 
received at theiqbound LIM module 320. In steps ST2 and ST3, the incoming 
ISUP IAM message^ received and processed by the MTP Level 1 and 2 
20 processes 322 and 324, ?^spectively. With MTP Level 1 and 2 processing 
complete, the signaling message packet is temporarily buffered in the I/O 
queue 325 before being passed upNtie stack to the MTP Level 3 Gateway 
Screening (GWS) process 326. As indicated in step ST4, GWS process 326 
examines the incoming ISUP IAM message am( determines not only whether 
25 the message is to be allowed into the switch for fQrther processing, but also 
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whicft. if any, of the provisioned stop actions are applicable to the incoming 
message. In this example, GWS process 326 examines the incoming ISUP 
1AM message and determines that the message is permitted to enter the 
switch. Furthermore, upon examination of the Originating Point Code (OPC), 
5 Destination Point Code (DPC) and Service Indicator Octet (SIO) fields 
contained in the MTP routing layer, it is determined that the message requires 
additional processing \y the PRR stop action 328 (ST5). In steps ST6 PRR 
stop action process 328 receives the ISUP 1AM message from GWS process 
326 and determines that ttite incoming message is an ISUP type MSU. The 

10 PRR stop action process 32li next checks the DPC of the incoming MSU. 
More specifically, the PRR steA action verifies that the DPC of the incoming 
MSU is a valid PC. PRR stop action 328 examines the incoming MSU to 
determine whether presence registration service is required. If the incoming 
MSU is identified as being an ISUP IAM type message, PRR stop action 328 

15 encapsulates a copy of the ISUP IAM\ message within an SCCP formatted 
MSU, as indicated in step ST6. Such\SCCP encapsulation is effectively 
achieved by adding essential SCCP message leading and trailing bit 
sequences to the base bit sequence that comprises the ISUP IAM MSU, as 
generally illustrated in Figure 6. Thus, an SCOP type encapsulated MSU is 

20 created which envelops or contains an ISUP type\MSU. Subsequent to this 
encapsulation, the incoming message no longer appears or is treated as an 
ISUP IAM message within the presence registration anil routing node 300, but 
is instead processed internally as an SCCP type SS7 message. 

Unless additional processing by an unrelated subsystem is required, 

25 the original ISUP IAM MSU is then routed directly to HMDC process 330 
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where normal ISUP MSU type routing is resumed. However, once again, it 
should be appreciated that the original ISUP IAM MSU could be SCCP 
encapsulated and further processed instead of producing a copy of the ISUP 
MSU. It should also be appreciated that failure of the incoming ISUP MSU to 
meet the criteria specified in step causes the original, non-encapsulated MSU 
to be routed directly to HMDC process 330 where normal ISUP MSU type 
routing is resumed. 

l^owever, in the case where an incoming ISUP MSU satisfies the ST5 
criteria, SiSCP encapsulation of the ISUP MSU occurs and the resulting 
10 encapsulatedNMSU is directed to HMDC process 330 (ST7), where SCCP 
type processingNis performed. In the example shown in Figure 3, HMDC 
process 330 examines the message packet and determines that the DPC and 
Subsystem Number (SSN) of the SCCP packet is the PC of the presence 
registration and routing nbde. Consequently, further processing of the SCCP 
15 MSU within the routing nodte is assumed to be necessary, and the packet is 
passed to the HMDT process\332. The HMDT process 332 examines the 
Service Indicator (SI) field of the^ncapsulated MSU, which indicates that the 
V encapsulating packet is of an SC&P type. As such, HMDT process 332 
places the encapsulated SCCP MSU on high speed IMT bus 310 for transport 
20 to PRM 340 and subsequent presence registration service. 

Referring to Figure 5b, in step ST8, \he encapsulated SCCP MSU is 
received and examined by SCRC process 342\that is resident on PRM 340. 
SCRC process 342 examines the message, determines that presence 
registration service is indicated, and forwards the encapsulated MSU to the 
25 PRMG process 344, as indicated by step ST9. In step ST10, PRMG process 



844 extracts the ISUP 1AM MSU from the SCCP envelope and determines 
that the ISUP MSU requires the generation of a SIP-formatted presence 
registration message (ST11). The ISUP IAM MSU is subsequently directed to 
SIP application 348 for further processing (ST12). SIP application 348 
5 examines tne ISUP IAM MSU and, using information contained within the 
MSU, generates, a SIP-formatted presence registration message (ST13). 

With SIP processing complete, the SIP-formatted presence registration 
message is passed tb HMRT process 350. HMRT process 350 determines to 
which ADCM card the SIP registration message packet should be routed for 

10 subsequent outbound transmission (ST14). In this case, the HMRT process 
350 determines that the desired outbound signaling link associated with the 
routing of the SIP registration message is located on ADCM 360. 
Consequently, the SIP messageNpacket is internally routed across the IMT 
bus 310 to LIM 360, where it is generally received by the I/O queue process 

15 362 (ST15). Eventually, the modified message packet is passed from the I/O 
queue 362 on to the IP Level 2 andNLevel 1 processes 364 and 366, 
respectively (ST16). Once again, IP level \ and 2 processes 366 and 364, 
respectively, provide the facilities necessary tto send and receive digital data 
over a particular physical media / physical interface, as well as to provide 

20 error detection / correction and sequenced deliverXof all IP message packets 
transmitted into the IP network. As indicated in stepBT17, the SIP-formatted 
presence registration message is then transmitted into an IP network for 
ultimate delivery to and use by a presence database system. 

It will be appreciated that the registration message generation 

25 methodology shown in Figure 4 is fundamentally similar to the process 
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ideated in Figures 5a and 5b. The primary difference involves processing 
variations that result from the handling of SS7 ISUP versus SS7 TCAP type 
messagea\Most notably, since a TCAP message is, in fact, also an SCCP 
message, there\is no need to directly encapsulate or copy and encapsulate 
5 the incoming TCAP message. Instead the TCAP message is simply directed 
from the inbound LIM 32(Ttatthe associated PRM 340 via the high speed IMT 
Bus 310, in much the same manner as the SCCP encapsulated ISUP IAM 
described in detail above. As such/^igure 7 presents a flow chart of the 
major steps associated with the proce^ing of a TCAP-type presence 

10 registration request message, which may be\jsed in conjunction with the 
schematic diagram shown in Figure 4 to better understand the TCAP based 
presence registration message generation methodology. 

With particular regard to the scenario generally illustrated in Figure 4, 
an incoming TCAP-formatted presence registration request message is 

15 received at the inbound LIM module 320 (ST1). Once again, in steps ST2 
and ST3, the incoming TCAP message is received and processed by the MTP 
Level 1 and 2 processes 322 and 324, respectively. With MTP Level 1 and 2 
processing complete, the signaling message packet is temporarily buffered in 
the I/O queue 325 before being passed up the stack to the MTP Level 3 

20 Gateway Screening (GWS) process 326. As indicated in step ST4, GWS 
process 326 examines the incoming TCAP message and determines not only 
whether the message is to be allowed into the switch for further processing, 
but also which, if any, of the provisioned stop actions are applicable to the 
incoming message. In the scenario shown in Figure 4, GWS process 326 

25 examines the incoming TCAP message and determines that the message is 




permitted to enter the switch. Furthermore, upon examination of the 
Originating Point Code (OPC), Destination Point Code (DPC) and Service 
Indicator Octet (SIO) fields contained in the MTP routing layer, it is 
determined that the message does not require additional processing by the 
5 PRR stop action 328. As such, the TCAP MSU is then routed directly to 
HMDC process 330 where SCCP type processing is performed (ST5). In the 
example shown in Figure 4, HMDC process 330 examines the message 
packet and determines that the DPC and Subsystem Number (SSN) of the 
TCAP packet is the PC of the presence registration and routing node. 

10 Consequently, further processing of the TCAP MSU within the routing node is 
assumed to be necessary, and the packet is passed to the HMDT process 
332. The HMDT process 332 examines the Service Indicator (SI) field of the 
TCAP MSU, which indicates that the packet is of an SCCP type. As such, 
HMDT process 332 places the TCAP MSU on high speed IMT bus 310 for 

15 transport to PRM 340 and subsequent presence registration service. 

\n step ST6, the TCAP MSU is received and examined by SCRC 
process 342 that is resident on PRM 340. SCRC process 342 examines the 

v message, determines that presence registration service is indicated, and 
^forwards the TCA^\MSU to the PRMG process 344. As indicated in step 

20 / ST7, the content of the TCAP message is examined to determine whether the 
/ TCAP presence registration request requires the generation of a SIP- 
/ formatted message. In this example, it is assumed that the TCAP registration 
request message requires a SIRformatted response and as such, is 
subsequently directed to SIP applicatiism 348 for further processing. SIP 

25 application 348 examines the TCAP MSlXand, using information contained 
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wit(iin the MSU, generates a S IP-formatted presence registration message 

\ 

(ST8\ 

\ 

Wit(i SIP processing complete, the S IP-formatted presence registration 

\ 

message is passed to HMRT process 350. HMRT process 350 determines to 

\ 

5 which ADCM card the SIP registration message packet should be routed for 
subsequent outbourkj^transmission (ST9). In this case, the HMRT process 
350 determines that the\desired outbound signaling link associated with the 
routing of the SIP registration message is located on ADCM 360. 
Consequently, the SIP message packet is internally routed across the IMT 

10 bus 310 to LIM 360, where it is generally received by the I/O queue process 
362 (ST10). Eventually, the modified, message packet is passed from the I/O 
queue 362 on to the IP Level 2 arusl Level 1 processes 364 and 366, 
respectively (ST11). As indicated in step^ST12, the SIP-formatted presence 
registration message is then transmitted into an IP network for ultimate 

15 delivery to and use by a presence database systtem. 

Shown in Figures 8, 9 and 10 are simplified network diagrams that 
illustrate example implementations of the embodiments described above. 
More particularly, Figure 8 illustrates an implementation of the presence 
registration and routing node 300 of the present invention in a mobile or 

20 wireless telecommunications environment, generally indicated hv the numeral 
400. Network 400 includes a mobile subscriber 402, a base station complex 
404, a mobile switching center (MSC) 406, a home location register (HLR) 
408, and a presence server 410. It will be appreciated that the messagfe flows 
shown in Figure 8 indicate that the presence registration and routing node\300 

25 formulates and transmits a presence registration message 416 in response id 



the\eceipt of a location update message 412 that is sent from the MSC 406. 
Those^skilled in the art of wireless telecommunications will appreciate that an 
MSC perwms a number of functions in a wireless network, including the 
formulation ai^d routing of signaling messages. In the example shown in 
5 Figure 8, the location update signaling message used by the presence 
registration and routWj node 300 to trigger the presence registration message 
416 is destined for the\HLR node 408. In such a wireless scenario, the 
presence registration message 416 could be formulated and transmitted by 
the presence registration ana\routing node in response to a mobile location 

10 update message associated with the registration of a wireless customer in a 
particular cell or service area. Once again, those skilled in the art of wireless 
or mobile telecommunications will appreciate that wireless or mobile signaling 
messages are generated and transrrutted within a wireless network in 
response to the powering-up or turning-on\pf a customer's wireless phone, as 

15 well as in response to inter-cell movement of a mobile subscriber during the 
course of a mobile call. As such, the presenc^ registration and routing node 
of the present invention facilitates a method of ^presence registration that is 
completely transparent to the cell or mobile phone user. 

Figure 9 illustrates an implementation of the presence registration and 

20 routing node 300 of the present invention in a wired telecommunications 
environment, generally indicated by the numeral 420. Network 420 includes a 
wireline subscriber 422, an end office (EO) 424, and a presence server 426. 
It will be appreciated that the message flows shown in Figure 9 indicate that 
the presence registration and routing node 300 formulates and transmits a 

25 presence registration message 434 in response to the receipt of an ISOJP call 
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\ signaling message from the EO 424. More particularly, the presence 
registration message 434 is generated in response to the receipt of an ISUP 
Initial Address Message (1AM) message 428. Those skilled in the art SS7 

signaH^ig will appreciate that an ISUP 1AM message is the first in a sequence 

\ 

5 of ISUP formatted SS7 call control signaling messages that are required to 
complete a^hone call in the Public Switched Telephone Network (PSTN). As 
such, it will be\appreciated that in the scenario illustrated in Figure 9, the 
presence registration message 434 is formulated in response to an attempt by 
the wireline subscriber 422 to place a telephone call. As presence registration 

10 message generation ik triggered by an ISUP IAM message, it will be 
appreciated by those skiHed in the art of SS7 telecommunications that 
completion of an attempted\telephone call is not required in order for a 
presence registration message tb be generated and transmitted to a presence 
server. Thus, any call attempts by\the wireline subscriber 422 will effectively 

15 register the subscriber's presence with the presence server 426 via the 
presence registration and routing node >300 of the present invention. It will 
also be appreciated from Figure 9, that theyiggering ISUP IAM message 428 
is subsequently routed as normal, on to a destination address specified in the 
message. 

20 Shown in Figure 10 is a variation of the sctenario that was illustrated in 

Figure 9 whereby an SS7 signaling message useay to trigger the formulation 
and subsequent transmission of a presence registration message is 
comprised of a TCAP-type message instead of an\jSUP-type message. 
Shown in Figure 10 is an implementation of the presence registration and 

25 routing node 300 of the present invention in a wired telecommunications 




environment, generally indicated by the numeral 440. Network 440 includes a 
wrceline subscriber 442, an end office (EO) 444, and a presence server 446. 
In the particular embodiment shown in Figure 10, it is assumed that the 
wireline subsfeqber 442 indirectly initiates a TCAP message 448 by dialing 
"*88" or a similar c&de on a telephone keypad. Once again, those skilled in 
the art of SS7 telecommunication networks will appreciate that generation of 
such TCAP messages is abcomplished by an End Office (EO) or Service 
Switching Point (SSP) in response to the "*88" keystrokes, as generally 
indicated in Figure 10. As such, by dialing "*88" the wireline subscriber 442 is 
effectively manually registering their presence with the presence server via 
the generation of the TCAP message 448. which in turn causes the 
generation of a presence registration messagb, 450 by the presence 
registration and routing node 300 of the present invention 



Integrated Presence Database System 
The embodiments of the present invention described in detail above 
can be easily^tended to include a presence registration and routing node 
that is capable of maintaining a presence database system. One embodiment 
of such a presence registration and routing node is illustrated in Figure 1 1 , 
and generally indicated by the s Rumeral 500. It will be appreciated that in the 
particular embodiment presently\qontempiated, presence registration 
messages are not formulated and routed from the node, but instead presence 
registration takes place at or within the node. That is, in the embodiment of 
the present invention shown in Figure 1 1 and generaltysdiscussed below, the 
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^nctionality of a presence server is generally included within the presence 
registration and routing node 500. 

particular regard to the embodiment illustrated in Figure 1 1 and in 
a manner sin^Jar to the embodiment described above, it will be appreciated 
5 that presence registration and routing node 500 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules oK cards including; a pair of Maintenance and 
Administration Subsystem \Processors (MASPs) 312, an SS7 capable Link 
10 Interface Module (LIM) 320, an IP capable Advanced Database 
Communication Module (ADCM) 360, and a Presence Database Module 
(PDM) 502. These modules arev physically connected to the IMT bus 310 
such that signaling and other type messages may be routed internally 
between all active cards or modules. For simplicity of illustration, only a single 
15 LIM 320, ADCM 360, and PDM 502 are included in Figure 11. However, it 
should be appreciated that the distributee^ multi-processor architecture of the 
presence registration and routing node 500 facilitates the deployment of 
multiple LIM, ADCM, PDM, and other c\rds, all of which could be 
simultaneously connected to the IMT bus 310. 
20 As in the previously described embodiment, MASP pair 312 implement 

the overall maintenance and administration subsystem functions. For a 
comprehensive discussion of additional MASP operations and functionality, 
the above-referenced Tekelec publications can be consulted. 

Once again, it witkbe appreciated that LIM 320 is comprised of a 
number of sub-component profce^ses including, but not limited to; an SS7 
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l\^TP level 1 process 322, an SS7 MTP level 2 process 324, an I/O buffer or 
queue 325, a gateway screening (GWS) process 326, a Presence Server 
Request (PRR) stop action process 328, an SS7 MTP level 3 layer HMDC 
process 33Q, and an HMDT process 332. MTP level 1 and 2 processes 322 
5 and 324, respectively, provide the facilities necessary to send and receive 
digital data over a particular physical media / physical interface, as well as to 
provide error detection / correction and sequenced delivery of all SS7 
message packets. \l/0 queue 325 provides for temporary buffering of 
incoming and outgoing\signaling message packets. GWS process 326 is 

10 responsible for examininemhe incoming signaling message and determining 
which, if any, of the provisioned stop actions are applicable. PRR stop action 
process 328 is responsible Tor making a copy of, and subsequently 
encapsulating, an incoming SSAISDN User Part (ISUP) IAM signaling 
message packet within an SS7 Signaling Connection Control Part (SCCP) 

15 formatted packet. It should be appreciated that PRR stop action process 328 
could also be configured to simply encapsulate the original incoming SS7 
ISUP IAM signaling message, without making^a copy. MTP level 3 HMDC 
process 330 receives signaling messages from the lower processing layers 
and performs a discrimination function, effectively otetermining whether an 

20 incoming SS7 message packet requires internal processihg or is simply to be 
through switched. For instance, in the case of an SS7 ^TCAP message 
associated with presence registration or an SCCP encapsulated ISUP IAM 
message, HMDC process 330 would determine that the message\should be 
internally routed for further processing. The HMDT process 332 manages or 

25 directs the internal routing of SS7 message packets that require addifopnal 
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processing^Rrior to final routing. Once again, it should be appreciated that a 
LIM card may contain more functional processes than those described above. 
The above discussionSs limited to LIM functionality associated with the basic 
processing of in-bound signaling messages. 

As such, it will be appreciated that the three functional processes 
associated with an Advanced Database Communication Module (ADCM) 360 
shown in Figure 11 are simply those processes that are relevant to a 
discussion of out-bound ADCM operation in the examples of PS routing node 
operation disclosed herein. Furthermore, it will be appreciated that ADCM 
360 is similar in function to the DCM application module described above. In 
the case of ADCM 360, the message packets processed by the card need not 
be native SS7 type messages that have been encapsulated in an IP packet. 
Instead, the ADCM 360 is capable of processing, transmitting, and receiving 
both native SS7 and native IP protocol messages. 



an I/O queue 362^30^ IP level 1 and 2 processes 366 and 364, respectively. 
I/O queue 362 facilitatesM^mporary buffering of incoming and outgoing 
signaling message packets, whiletPsaddressing operations are performed by 
the IP level 1 and 2 processes 366 ancT3(>4y respectively. 

Once again, the description of LIM and ADCM sub-components 
provided in the above description is limited to those sub-components that are 
relevant to the sample implementation scenarios discussed herein. For a 
comprehensive discussion of additional LIM and ADCM-type operations and 
functionality, the above-referenced Tekelec publications can be consulted. 




rocesses explicitly shown on the out-bound ADCM 360 include 
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general, a PDM card includes the database and database control 
processes necessary to facilitate the presence registration and query handling 
functionality of the contemplated embodiment of the present invention. The 
^ V PDM 502 shoWn in Figure 11 is comprised, in part, of an SCCP subsystem 
/5 controller known \as a Signaling Connection Routing Controller (SCRC) 
process 504, a Presfemce Database Manager (PDMG) process 510, and a 
number of Presence NDatabase Interface (PDI) Applications generally 
indicated by the numeral 5t2. Included among the PDI Applications 512 are 
session initiation protocol (S\P$ application process 518, IMPP application 
10 process 514, and presence protocol process 519. The SCRC process 504 is 
responsible for discrimination of ^signaling messages and subsequent 
distribution of these signaling messages, to an appropriate higher processing 
level application or function. In the configuration shown in Figure 1 1 , the next 
highest processing level is represented by the PDMG process 510. PDMG 
15 process 510 is generally responsible for determining which of the provisioned 
protocol-specific PDI Applications 512 is required process the incoming 
message packet. For instance, if the incoming presence registration packet 
contained a TCAP or SCCP-encapsulated IMPP mesgage, PDMG process 
510 would determine that the provisioned PDI application, 514 was required 
20 for successful processing. As will be appreciated from Figure^! 1 , a number of 
PDI applications 512 may be simultaneously provisioned on aSsingle PDMG 
card. These protocol-specific PDI applications may be configured such that 
each application is capable of receiving presence registration ^or query 
messages that are formatted in different protocols including, but not limtted to, 
25 SIP, IMPP, and the presence protocol. Furthermore, these PDI applications 
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112 are also capable of generating or formatting protocol-specific presence 
seMce related response messages. Such a presence service response 
message, might include, but is not limited to, a message that provides 
presence states information for a specific user in response to a presence 
5 status query. ThiSvparticular scenario is specifically illustrated in Figure 11, 
where the presence status query packet assumes the form of an SS7 TCAP- 
encapsulated IMPP query message and the subsequent presence status 
response is contained within^ SIP formatted message. 

Once again, while any Vimber or variety of PDI applications may be 
10 provisioned on a single PDM carckonly the IMPP, SIP, and presence protocol 
PDI applications 514, 518, and 51 Jrl respectively, are described herein. SIP 
PDI application 518 essentially contains the logic necessary to process 
incoming SIP presence messages and construct outgoing SIP presence 
response messages. Similarly, IMPP PD\ application 514 contains the logic 
15 necessary to process incoming IMPP formatted presence messages and 
construct outgoing IMPP formatted presence response messages. Presence 
PDI application 519 contains the logic necessary to process incoming 
presence query messages formatted according tfo the presence protocol and 
construct outgoing presence response messages formatted according to the 
20 presence protocol. 

Also included in Figure 1 1 is a general message flow associated with 
the processing of an incoming SS7 TCAP-encapsulated IMPP formatted 
presence query message and the subsequent, related presence system 
processing activity. A detailed flow chart of the major steps associated with a 
25 TCAP-encapsulated IMPP presence query scenario is presented in Figure 12, 
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and may be used in conjunction with the schematic diagram shown in Figure 
11 to better understand the operation of presence registration and routing 
node 500. 

ith particular regard to the scenario generally illustrated in Figure 11, 
it is assumed that an incoming TCAP-encapsulated IMPP formatted presence 
query message is received at the inbound LIM module 320 (ST1). Once 
again, in steps\ST2 and ST3, the incoming TCAP-encapsulated IMPP 
formatted presence\auery message is received and processed by the MTP 
Level 1 and 2 processes 322 and 324, respectively. With MTP Level 1 and 2 
processing complete, the signaling message packet is temporarily buffered in 
the I/O queue 325 before b&ng passed up the stack to the MTP Level 3 
Gateway Screening (GWS) process 326. As indicated in step ST4, GWS 
process 326 examines the incomiha TCAP presence query message and 
determines not only whether the message is to be allowed into the switch for 
15 further processing, but also which, if any, erf the provisioned stop actions are 
applicable to the incoming message. In the\scenario shown in Figure 11, 
GWS process 326 examines the incoming \TCAP-encapsulated IMPP 
presence query message and determines that the Nriessage is permitted to 
enter the switch. Furthermore, upon examination of\the Originating Point 
20 Code (OPC), Destination Point Code (DPC) and Service Indicator Octet (SIO) 
fields contained in the MTP routing layer, it is determined that the message 
does not require additional processing by the PRR stop action j28. As such, 
the TCAP MSU is then routed directly to HMDC process 330 where SCCP 
type processing is performed (ST5). In the example shown in Figure 11, 
25 HMDC process 330 examines the message packet and determines thgt the 
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\ DPC and Subsystem Number (SSN) of the TCAP packet is the PC and SSN 
c^he internal presence server database system that is located on PDM card 
502. Consequently, further processing of the TCAP MSU within the routing 
node is assumed to be necessary, and the packet is passed to the HMDT 
5 process 332. ^"he HMDT process 332 examines the Service Indicator (SI) 
field of the TCAP AdSU, which indicates that the packet is of an SCCP type. 
As such, HMDT process 332 places the TCAP MSU on high speed IMT bus 
310 for transport to PDM\502 and subsequent presence database service. 

In step ST6, the fCAP MSU is received and examined by SCRC 

10 process 504 that is resident on PDM 502. SCRC process 504 examines the 
message, determines that presence database service is indicated, and 
forwards the TCAP MSU to the PDMG process 510. As indicated in step 
ST7, the message packet is exammed to determine the protocol of the 
presence related message. In this case^, the protocol of the presence related 

1 5 message encapsulated within the TCAP packet is IMPP. Next in step ST8 the 
variety or type of presence service associated with the message is evaluated. 
Such general presence message types or varieties might include, but are not 
limited to, query and registration type messages\ 

Once again, in this example, the IMPP-formatted presence service 

20 message is a query message that is intended to extract information from a 
presence service database. As such, the IMPP formatted query message is 
directed to IMPP application 514 for further processing. IMPP application 514 
examines the message and, using information contained within the packet, 
directs the query to presence database 516 (ST9). Presence database 516 

25 processes the query and, in this example, returns the requested information to 



SIP application 518 for formatting of the out-bound response message 
(ST10). 

With the necessary SIP formatting complete, the S IP-formatted 
presence registration message is passed to an HMRT process 520. HMRT 
5 process 520 determines to which ADCM card the SIP registration message 
packet should be routed for subsequent outbound transmission (ST11). In 
this case, the HMRT process 520 determines that the desired outbound 
signaling link associated with the routing of the SIP registration message is 
located on ADCM 360. Consequently, the SIP message packet is internally 

10 routed across the IMT bus 310 to LIM 360, where it is generally received by 
the I/O queue process 362 (ST12). Eventually, the modified message packet 
is passed from the I/O queue 362 on to the IP Level 2 and Level 1 processes 
364 and 366, respectively. As indicated in step ST13, the SIP-formatted 
presence registration message is then transmitted into an IP network for 

1 5 ultimate delivery to and use by a presence database system. 

It will be appreciated from Figure 12, that if the IMPP-formatted 
presence service message were a registration request-type message, then 
IMPP application 514 would examine the message and, using information 
contained within the packet, direct the registration request to presence 

20 database 516 (ST14). In such a scenario, a response or acknowledgment 
message may not necessarily be required. 



25 



Externally Mounted Presence Database System 
The embodiments of the present invention described in detail above 
can be easily extended to include a presence registration and routing node 
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that incorporates an externally mounted presence database system or server 
platform. One embodiment of such a presence registration and routing node 
is illustrated in Figure 13, and generally indicated by the numeral 600. Once 
again, it will be appreciated that in the particular embodiment presently 
5 contemplated, presence registration messages are not formulated and routed 
from the node, but instead presence registration takes place at or within the 
node. 

with particular regard to the embodiment illustrated in Figure 13 and in 

\ 

a manner similar to the embodiment described above, it will be appreciated 
10 that presence\egistration and routing node 600 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
^processing modules or\cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312, an SS7 capable Link 
Interface Module (LIM) 32<K an IP capable Advanced Database 
Communication Module (ADCM) 360, and an External Presence Database 
Module (EPDM) 700. As further indicated in Figure 13, EPDM is connected to 
an external Presence Database Server\platform 800 via a high-speed 
Ethernet-type connection 802. In this enW>diment, external Presence 
20 Database Server platform 800 includes the actuaKPresence Database entity 
516. With exception of the EPDM card 700 and external Presence Database 
Server 800, all other functional and operational aspectkof the embodiment 
shown in Figure 13 are identical to that of the embodiment sl\own in Figure 1 1 
and generally described above. 
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n general, 



an EPDM card 700 includes the database and database 



control processes necessary to facilitate the presence registration and query 
handling functionality of the contemplated embodiment of the present 
invention. The EPDM 700 shown in Figure 13 is comprised, in part, of an 
5 SCCP subsystem (rontroller known as a Signaling Connection Routing 
Controller (SCRC) process 504, a Presence Database Manager (PDMG) 
process 510, and a irumber of Presence Database Interface (PDI) 
Applications generally indicated by the numeral 512. Included among the PDI 
Applications 512 are a session initiation protocol (SIP) application process 
10 518, an IMPP application process\514, and a presence protocol process 519. 
The SCRC process 504 is responsible for discrimination of signaling 
messages and subsequent distribution of these signaling messages to an 
appropriate higher processing level ^application or function. In the 
configuration shown in Figure 13, the next highest processing level is 
15 represented by the PDMG process 510. PDMG process 510 is generally 
responsible for determining which of the provisioned protocol-specific PDI 
Applications 512 is required process the incomingVnessage packet. The PDI 
applications 512 are capable of generating or formatting protocol-specific 
presence service related response messages. Such a presence service 
20 response message might include, but is not limited to, a message that 
provides presence status information for a specific userVin response to a 
presence status query. 

In the embodiment shown in Figure 13, EPDM card 700 further 
includes an Ethernet Controller (EC) process 702 which is communicatively 
25 coupled to the provisioned PDI applications 512 and also to the external 



Presence Database Server 800. More particularly, EC 702 is coupled to a 
corresponding EC process 802 that resides on the external Presence 
Database Server 800. ECs 702 and 802 facilitate the communication of 
messages between the PDI applications 512 and the Presence Database 
5 516. In all other respects, operation of the presence registration and routing 
node is identical to that of presence registration and routing node 500 
described above and illustrated in Figure 11. 




Integrated Message Accounting And Billing Subsystem 
10 Shown in Figure 14 is another embodiment of a presence registration 

and routing node of the present invention, generally indicated by the numeral 
900. With particular regard to the embodiment illustrated in Figure 14 and in a 
manner similar 10 the embodiment described above, it will be appreciated that 
presence registration and routing node 900 includes a high speed 
15 Interprocessor Message Transport (IMT) communications bus 310. As in the 
previously described embodiments, communicatively coupled to IMT bus 310 
are a number of distributed processing modules or cards including; a pair of 
Maintenance and AdministrationNSubsystem Processors (MASPs), an SS7 
capable Link Interface Module (LIM) 320, and an IP capable Advanced 
Database Communication Module (ADCM^360, and a Presence Registration 
Module (PRM) 340. Further included in the presence registration and routing 
node 900 is an accounting and billing subsystem which is comprised of an 
accounting subsystem interface module (ASIM), generally indicated by the 
numeral 910, and an accounting server platform (ASP), generally indicated by 
25 the numeral 920. It will be appreciated that the combinationVf ASIM card 910 
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and ASP accounting server 920 includes the database and control processes 
necessary to achieve the accounting and billing functionality of the present 
invention From a practical implementation standpoint, ASP 920 could 
assume thckform of a Sun Workstation or similar type computing platform. It 
5 will be further\appreciated that an entire message accounting subsystem 
could also be integrated within a presence routing and registration node. 

The ASIM <sard 910 shown in Figure 14 includes a Signaling 
Connection Control Ftert (SCCP) subsystem 912 that is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 

10 accounting message pacKets. ASIM card 910 also includes an SCCP 
controller known as a Signaling Connection Routing Controller (SCRC) 
process 914 and a high-speed Ethernet Controller (EC) process 916. Once 
again, as described above, the SCCP subsystem 912 is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 

15 message packets, while the SCRcXprocess 914 is responsible for 
discrimination and subsequent distribution of messages based on information 
contained in an SCCP packet. In the case of \siM card 910, messages that 
satisfy the SCRC discrimination criteria are distriauted or directed to the high- 
speed Ethernet Controller process 916. EC process\916 is in turn responsible 

20 for controlling the process of communicating messages, via an Ethernet 
connection to and from the associated ASP server 920V More particularly, 
ASP server 920 includes a corresponding high-speed Ethernet Controller 
process 922 that serves as the communications interface between ASIM card 
910 and an on-board accounting server manager (ASM) process\924. ASM 

25 process 924 is responsible for the de-capsulation or removal of the SCCP 
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Wwelope that contains the accounting message. The de-capsulated 
accenting message is then passed to an adjacent usage and measurements 
proces^^ where usage and measurement statistics are created and stored 
in a usage ^mb\measurements database (UMD) process 930, such as that 
shown in Figure 15. 

Usage and measurements statistics produced by such a process could 
include, but are not limited, to, peg counts of messages received from a 
specific network address, a specific service provider, a specific service user, a 
specific IP socket, or a specific^ signaling link. Furthermore, information 
10 specific to the type of service requested, calling and called party information, 
and other information associated with acommunication that could be useful in 
generating a bill or invoice may also be stored in a UMD. As shown in sample 
UMD process 930, in one simplified embodiment, each communication is 
identified by a transaction ID, and certain predetermined information 
15 associated with a communication can be stored\in the database. It will be 
appreciated that the information contained in a CJMD database could be 
significantly more or less detailed than that indicated i\the example shown in 
Figure 15. 

In any event, such statistics could include information associated with 
20 the time-of-day that a message was received, the duration of a "call" or 
communication, general quality of service (QoS) indicators associated with a 
"call" or communication, information related to or identifying the type of 
service that is associated with a "call" or communication (i.e., broadband 
service related, call setup related, database query related, etc.). Such usage 
25 information could be used to bill a subscriber at different rates depending 




upon the type of service requested. With such capability included within a 
presence server and routing node, network operators greatly increased 
flexibility with regard to service-specific billing, without significantly increasing 
network OA&M requirements. 
5 In order to facilitate such billing operations, ASP server 920 also 

includes a billing process 928 that is adapted to extract information stored by 
the usage and measurements process 926 and subsequently generate bills. 
Once again, information or parameters maintained by process 926 that may 
be used in the generation of bills could include, but is not limited to, a network 

10 address identifier, a service provider identifier, a service user identifier, an IP 
socket identifier, a signaling link identifier, and a service type identifier. It will 
be further appreciated that a network address identifier could include, but is 
not limited to a destination or origination SS7 point code, a destination or 
origination IP address, and a destination or origination domain name. 

15 Similarly, a user identifier could include, but is not limited to a calling or called 
party telephone number, and a destination or origination email address. 

In the particular embodiment shown, LIM card 320 includes a Presence 
Registration Request (PRR) stop action process 902, that is functionally 
similar to the PRR process 328 described above. In addition to generate, and 

20 SCCP encapsulate an accounting message that is subsequently passed via 
IMT bus 310 to ASIM 910 of the accounting and billing subsystem. 

In a preferred embodiment, a normalized accounting message (NAM) 
format is employed to provide the necessary message information content to 
the associated accounting and billing subsystem. That is, a NAM formatted 

25 accounting message employs a field or record structure that is essentially a 
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superset of all parameters of interest from all signaling, presence and instant 
messaging protocols of interest. As such, parameters of interest in a SIP 
formatted signaling message can be easily accommodated in a NAM 
accounting message, as can parameters of interest in an SS7 formatted 
5 signaling message. It will be further appreciated that the NAM format can be 
periodically expanded (or revised) to accommodate new or evolving signaling 
protocols that must be supported by a presence registration and routing node 
of the present invention. LIM card 320 can also be configured to simply 
encapsulate a copy of the received signaling message packet and forward the 

10 packet to the associated accounting and billing subsystem. 

With regard to the message encapsulation discussed above, it should 
be appreciated that SCCP encapsulation of a NAM message is not essential 
to the operation of the message accounting subsystem of the present 
invention. Other internal encapsulating protocols could be just as easily 

15 employed, provided that a suitably provisioned ASIM module is capable of 
receiving and processing the encapsulated messages. In fact, no 
encapsulation necessarily need be performed, so long as the accounting 
message generated by a PRR type process can be received and generally 
processed by a suitable configured ASIM module. 

20 Figure 16 illustrates yet another embodiment of a presence registration 

and routing node of the present invention, which extends the integrated 
--7 accounting and billing subsystem concept to the routing node previously 

^ presented in Figure 11. This new^mbodiment of a presence server and 
^ routing node is generally indicated by the^numeral 950. With particular regard 

25 to the embodiment illustrated in Figure 16 arqd in a manner similar to those 



erifcodiments described above, it will be appreciated that presence 
registration and routing node 950 includes a high speed Interprocessor 
Message^ transport (IMT) communications bus 310. Communicatively 
coupled to IMTNbus 310 are a number of distributed processing modules or 
5 cards including; a\pair of Maintenance and Administration Subsystem 
Processors (MASPs), ata SS7 capable Link Interface Module (LIM) 320, and 
an IP capable Advanced Database Communication Module (ADCM) 360, and 
a Presence Registration Module (PRM) 340. Further included in the presence 
registration and routing node 9m) is an accounting and billing subsystem 
Q 10 which is comprised of an accounting subsystem interface module (ASIM), 
21 generally indicated by the numeral 9\o, and an accounting server platform 

^ (ASP), generally indicated by the numeral 920. Again, it will be appreciated 

f!J that the combination of ASIM card 910 and ASP accounting server 920 

q includes the database and control processes necessary to achieve the 

ni 15 accounting and billing functionality of the present invention. 

In the particular embodiment shown, LIM cara\320 includes a Presence 
Registration Request (PRR) stop action process 952, that is functionally 
similar to the PRR process 902 described above. PRR\952 is adapted to 
generate, and SCCP encapsulate, an accounting message that is 
20 subsequently passed via IMT bus 310 to ASIM 910 of the accounting and 
billing subsystem, where accounting and billing subsystem processing occurs 
in a manner similar to that described above. 

It will be understood that various details of the invention may be 
changed without departing from the scope of the invention. Furthermore, the 
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foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation — the invention being defined by the claims. 
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